Today's software applications continue to grow in size and complexity. As a result, many applications, such as enterprise software applications that are deployed by organizations to implement business processes for example, are constructed from various components that are written in different programming languages and run in different runtime environments or on different platforms. Communications interfaces have been developed to enable such disparate application components to talk to each other; these interfaces usually employ a set of routines based on standard software specifications that are either widely used and accepted or are sanctioned by standards organizations.
An example of one such communications interface is the SAP Java Connector (“JCo”). The JCo was developed because most SAP business applications are programmed in SAP's ABAP programming language and run in the SAP R/3 system, but many application components have recently been developed in Java to take advantage of the interoperability fostered by the Java Virtual Machine runtime environment. The JCo interface enables Java clients to execute remote function calls to the R/3 system and vice-versa based on the Remote Function Call interface developed by SAP. A “remote function call” for the purposes of this application refers to a set of instructions that invoke an external software component (e.g., any type of routine, module, procedure or function). The remote function call may pass input parameters to the external software component and return output parameters resulting from the execution of the external component. An external software component refers to a software component that resides in a different physical location, is run in a different runtime environment, or is run on a different platform than the calling software component.
One disadvantage with such communications interfaces is that they require a developer of a software component to have a significant level of detailed knowledge of the technical aspects of the interface in order to correctly program the component to communicate with an external software component. Not only does the developer need to set the parameters (if any) for each remote function call and get the return parameters (if any) after execution of the remote function call, the developer also needs to program low-level execution details of the call that are irrelevant to the purpose of the particular remote function call to be made. Such implementation details include creating a connection to the remote system which hosts the external software component, performing error-checking routines, etc. When working on software components that include hundreds of remote function calls, this programming effort places an excessive burden on the developer.
Accordingly, there is a need in the art for a system and method for processing remote function calls without requiring developers to have a significant amount of technical understanding of the underlying communications interface.